High-Level View of Security in APIs

Introduction#

We have explored several topics on API security in this chapter. Before wrapping up, we’ll explore some significant concepts and models in the API security landscape. Studying these concepts will enable us to architect secure APIs. We’ll explain the following topics:

• Scope of APIs: Discusses the types and users of APIs

• Cybersecurity models: Security models that are applicable to APIs

These concepts aid in the overall security and functionality of APIs, so we’ll go over them before we end the chapter on security. Let's begin by examining the scopes of APIs.

Public and private APIs#

When we examine APIs, there are two significant concerns regarding API consumers:

• Who is the intended user of an API?

• Where is the API made available, and where can someone access the API on the network?

These points may be referred to as the scope of the API, so let's expand on these concepts.

Intended users#

There are three categories when we examine who an API is intended/designed for.

• Private: These are intended for consumption for users inside the organization, such as employees. These still might be exposed outside of an organization because the company/business itself may have external components outside that require access. An example of such an API could be a messaging portal that the organization solely uses for communication. However, such APIs are not available to the general public.

• Partner: These are APIs we design to communicate with established partners. The API is intended to be used outside the organization, perhaps in tandem with other APIs. The usage of such APIs usually comes with special terms and conditions that the partners or consumers have to agree to. Twitter's API is an example of a partner API because it has several tiers (elevated or elevated+) to denote a third party's approval status.

• Public: These are open APIs that the general public can access through an API directory. They’re typically easy to sign up for and use, but the developer may not have complete information about the users of the API. Facebook's open API that allows third parties to post on a user's newsfeed is an example of a public API.

While public APIs have their advantages, especially for those businesses aiming to launch their API to the public, they have some unavoidable security risks. Due to their open nature, they're easily targeted by attackers and put a strain on the server. Therefore, public APIs are usually distributed after implementing the security precautions that combat these risks.

In practice, most APIs would be public because everything these days is connected via the Internet, so it becomes more of a business decision than a technical decision.

Where is the API made available?#

Let's expand on how an API is exposed or made available to its users. There are two methods:

• Internal: These are inside an organization (within its firewalls, for example) and are not made publicly available on the network. They may provide access to sensitive information hosted internally on the system. Not all security measures will be required if it never communicates with external entities. Some companies use virtual private networks (VPNs) to communicate, and in this case, API calls won't be allowed to exit the organization’s VPN.

• External: These APIs are exposed on the Internet, and any user can attempt to access them. These APIs’ resources are exposed to communicate with other applications. They are not limited to use within the organization but are accompanied by the security risks associated with being exposed on the network.

The scope of the APIs can be summarized in the table below:

As we can see in the table above, public and partner APIs will always be externally available because they're available on the network. Now, let's finish off the chapter by expanding on cybersecurity models.

Cybersecurity models#

As the popularity of APIs has exponentially increased in the last few years, so have the attacks against them. This section attempts to highlight some security models that apply in the API landscape to mitigate security issues. We’ll focus on the Zero Trust model and Web Application and API Protection (WAAP). Let's begin by discussing the Zero Trust model.

Zero Trust model#

The Zero Trust model is a cybersecurity approach that eliminates trust and instead validates operations at each step to ensure total security. This consists of three components.

• Never trust the network: Assume that malicious actors are always present on the network the API is exposed to. Always act as if the network has already been breached and set up defenses accordingly.

• Verify explicitly: We shouldn't be under the assumption that whoever gets access to the API is legitimate and won't internally attack the API. This requires rigid authentication at all available data points for user identification.

• Limit privileged access: This refers to restricting user access to only the resources they require. This aids in data protection.

In broad terms, no client is trusted with the Zero Trust model.

Note: Interest in the Zero Trust model has grown recently because a trend of security breaches originating within organizations has surged. Attackers can bypass defenses and intrude internally on the network, so the Zero Trust model is key when implementing security. In particular, federal agencies have started adopting the approach because of its effectiveness.

Web Application and API Protection (WAAP)#

Another cybersecurity model to consider is Web Application and API Protection (WAAP), a security tool created to protect APIs and web applications. Its inception stemmed from the fact that traditional security methods weren't secure enough because the attack surface of APIs and web applications increased. WAAP was introduced by Adam Hils and Jeremy D’Hoinne of Gartner and is implemented as part of the third-generation web application firewall (WAF) by tech giants like Cloudflare, Google, Polaris, and so on. Let’s take a look at WAAP’s components in the image below:

WAAP typically uses artificial intelligence to detect and deter various attacks in real time. Generally, a WAAP solution is deemed secure if it fulfills the following needs:

• Anomaly detection: Adaptability is required to protect APIs against new threats. This is usually done by using artificial intelligence.

• System protection: Protection should be provided for the entirety of the system's web presence. This includes applications, APIs, and microservices.

• Rate limiting: Since APIs are publicly available, users may call them as often as they wish. This can bottleneck and overwhelm the services and functionalities an API has to offer. This complication can be solved through rate limiting, in which we constrain the number of requests users generate in a set period so that the maximum number of users can access the API.

• DDoS protection: This is crucial to ensure the availability and operation of our APIs and applications.

• Bot protection: WAAP solutions should be able to differentiate between nefarious bots and legitimate users and deal with them effectively.

Note: More and more companies are opting for WAAP, but the implementations differ due to each company’s specific needs.

Conclusion#

As we've learned in this chapter, the complexity of protecting APIs can make implementing security seem formidable. Nevertheless, it's more essential than ever because attacks evolve, and we constantly need security solutions that mitigate them. These solutions need to be scalable and more efficient in terms of speed. Interestingly, federal agencies are also getting involved, an example being the White House giving an order that implores Zero Trust to be employed for greater security.

There is an obvious tradeoff for higher security and performance, but this is sometimes deemed necessary in order to protect our APIs. We need to find the balance that ensures our APIs are not only secure but also run well enough to perform their tasks. It's an intricate balance because to increase either performance or security, we pay in terms of the other. We have to be vigilant because if we aren't careful, it could have major consequences. Even T-Mobile, a large service provider, experienced a significant data breach that affected 37 million people. With the large-scale and rapid development of APIs, even large corporations are having trouble implementing security in their APIs, so we have to be careful.